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1.0 INTRODUCTION 

The Executive Summary, (Volume 1, Final Report), was developed by the Space Systems 
Avionics Group of General Dynamics. It satisfies the requirements of Data Requirement 4 of 
the "Definition of Avionics Concepts for a Heavy Lift Cargo Vehicle" study for the Marshall 
Space Flight Center under contract NAS8-3578. 


1.1 SCOPE 

This document contains a summary of: 

• Significant achievements and activities of the study effort. 

• Results, methodologies and selected options 

• Trade Studies, recommended approaches, design impacts and analysis 

• Cost estimates of major elements of the Ground Based Testbed. 


1.2 BACKGROUND 

The HLCV avionics study was originally meant to focus the development of advanced 
avionics systems for the next ten to fifteen years. Figure 1 .2-1 shows the role the HLCV 
Avionics study was envisioned to play. Scoped to start with an expendable, Shuttle derived 
booster, it was to define an optimum progression of upgrades and transitions until a fully 
reusable fixed wing booster system was achieved. Not limited to boosters, the study was to 
explore second stages, recoverable modules, and the attendant ground support systems. 




SYSTEM TESTBED 
CONCEPT 
DEFINITION 



MULTIPROGRAM AVIONICS SYSTEMS TESTBED 


FIGURE 1.2-1 HLCV AVIONICS STUDY: FOCUS FOR AVIONICS ADVANCED DEVELOPMENT 
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FIGURE 1.2-2 HLCV / GBT IMPLEMENTATION 

Methods for accelerating the application of beneficial new technologies to existing and future 
systems were needed. To this end, a Ground Based Testbed was to be defined. Though not 
a stated goal, lowering the overall cost per pound of orbiting a payload drove the study to 
include the definition of the optimal mix of ground and airborne check out capability. 
Autonomous operation of the far term vehicles was felt to be a logical goal. 

Shortly after the first review, the customer directed a shift in emphasis to the definition of the 
Ground Based Testbed, (GBT), that would support development of the HLCV avionic 
systems. The HLCV reference vehicle avionic systems were defined to the level required to 
size the GBT main processor, G&N Extension, and interconnecting busses and networks. 

A target implementation schedule was provided by MSFC in October linking the HLCV GBT 
and.the Marshall Avionics System Test bed (MAST) efforts (see Figure 1.2-2.). Also defined 
were specific functional support levels with dates and projected budget allocations A 
candidate site for the GBT/MAST was also provided The third Quarter Review reflected these 
inputs and specifically costed the Phase 1 lab configuration. For purposes of this study the 
terms MAST and GBT are synonymous. 

The Executive Summary was structured to parallel the presentation at the 4th Quarter 
Review. It is intended to supplement the presentation and contains back-up information not 
included in the presentation materials. 


1.2.1 STUDY OBJECTIVES 

The initial objectives of the study were enumerated in the Study Plan as: 
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1 . Define the avionics requirements and recommended avionics concepts for 
an expendable Heavy Lift Cargo Vehicle in the 1992-1995 time span. 

2 . Define the avionics requirements and recommended avionics concepts for a 
highly reusable HLCV to be operational in the 2000 era. 


3. Define the requirements, concepts, developmental plans, and costs for an 
avionics test bed(s). The avionics test bed will support the development 
and testing of the recommended vehicle and vehicle support components, 

_®£|^i^|_S2^1|S2 ! ^H^§X|i|2£=iS£=J^liiSli=============s=======================J 

4 . Develop a transition plan from the expendable to the highly reusable HLCV. 

5 . Develop a follow-on plan to define advanced development activities. 

As previously stated, the study emphasis shifted to definition of the avionics test bed, 

Objective #3, shortly after the first Quarterly review. Details were hammered out in the August 
Technical Interchange Meeting (TIM). The study plan was changed and a no-cost contractual 
change initiated to offset the additional tasks and products associated with this change, 
objectives 4 and 5 were rescoped and de-emphasized. 


1.2.2 STUDY TASKS & SCHEDULE 

Figure 1. 2.2-1 is the revised Master Schedule that reflects the final contract changes. The six 
major task classifications are shown and the deliverables identified. 
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2.0 GBT DESIGN OBJECTIVES AND PHILOSOPHY 

The GBT is envisioned as a general resource facility providing to new vehicle programs a 
cost effective method of evaluating the concepts and technologies employed in their design. 
This resource will permit complete end-to-end simulations of system operation in the 
simulated mission environment desired. 

The GBT is to be set up to encourage use by all HLCV era vehicles during their initial design 
phases. Review of past projects involving total vehicle or subsystem development have 
repeatedly shown the need for such a readily accessible and powerful test and evaluation 
facility. The traditional dedicated test and development facilities have not been able to 
support their projects early enough to optimize system requirements and design. New 
projects must initially use facilities dedicated to other projects . Seldom do such facilities 
provide all the necessary testing capabilities or time for the required work. 

The key to the HLCV GBT success is seen to simply be: Cost Effectiveness . To obtain this 
objective, the Lab must be readily accessible at the time when new projects traditionally don't 
have their own dedicated facilities. GBT access must be simple and bound with a minimum of 
red tape. Once accessed, the GBT must provide a user friendly environment, an 
environment that can quickly be configured to access the required testing and logging 
resources. The resources must be capable of evaluating the concepts, technologies or 
designs to the required level of accuracy and against recognized performance benchmarks. 
Finally, the GBT must provide not only easy replication of the testing, but also provide the 
ability to thoroughly analyze the results and report the results in forms which effectively 
communicate their significance. 


2.1 GBT OBJECTIVES 

The major objectives for the GBT are to provide a cost effective, multiuser simulation, test and 
demonstration facility to: 

1. Support early development and quantitative evaluation of proposed avionics systems 
during the early phases, (phase A/B), of a program. 

• surfaces avionics, systems, integration and software problems early 

• supports early requirement s development 

2. Accelerate new avionics technology testing and application to future programs. 

3. Provide a productivity center for evaluating/demonstrating major new design advances 
from NASA and industry. 

4. Promote continuity of avionics architectures, software, and hardware across projects. 

5. Demonstrate the "integration-ability" of new subsystems or components and their 
impact on the performance of an existing vehicle system. 

Figure 2.1-1 shows four HLCV era vehicles to be supported by the GBT. The first two are 
shuttle derived vehicles, SDV-2ES and SDV-2R. The 2R version has reusable propulsion 
and avionics as opposed to being expendable as the 2ES is. An alternative to the SDV-2RS 
is the Advanced Launch System Core and Booster. The fourth GBT supportable vehicle 
shown is the Fully Reusable Booster/Partially Reusable Cargo Vehicle, FRWB/PRCV. In 
addition to these, the GBT will also support upper stages, the Space Transfer vehicles, and 
several payloads. 
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. SHUTTLE DERIVED 
EXPENDIBLE VEHICLE 

• IOC -1994 


SHUTTLE DERIVED 
VEHICLE W/REUSABLE 
PROPULSION/AVIONICS 

IOC -1997 


* ADVANCED LAUNCH 
SYSTEM CORE AND 
BOOSTER 

. IOC -1997 


. FULLY REUSABLE 
BOOSTER/PARTIALLY 
REUSABLE CARGO 
VEHICLE 

. IOC -2000 


FIGURE 2.1-1 HLCV ERA CANDIDATE VEHICLE CONFIGURATIONS 


2.2 GBT PHILOSOPHY 

The major points upon which the GBT design philosophy is based are: 

a. Reconfigurable Design 

b. Real Time 

c. Functional Testing 

d. Modular Design 

e. Flexible 

f. Demonstration Oriented 

g. User Friendly 

The broad based, non project dedicated, generic nature of the GBT is implied in the first 
point. The GBT must be an evolving facility, capable of supporting several current and near 
term avionic systems. This translates to a firm requirement for rapid reconfigurability. It must 
not only be able to switch from one test configuration to another, but it also must have 
sufficient capability to support several parallel efforts simultaneously. These efforts will 
include everything from basic evaluation of single units in an open loop environment, to full 
up, multi-string system simulation. 

To be truly useful to a number of projects simultaneously, the GBT must accommodate a 
variety of software and hardware configurations. This characteristic encompasses several 
traits which include an continuing capability to support several current and near term avionic 
systems. Implicit to this capability would be a rapid and easy reconfigurability made possible 
by an architecture that presents a broad compatibility to both hardware and software. This 
compatibility includes the ability to provide a Real-Time hardware and software interface. 

This interface must be capable of duplicating the normal interface the Unit Under Test 
encounters in its native system. Only with such an interface can testing and evaluation be 


Page 5 


9/27/89, 8:43 AM 



Final Report Volume 1 


Definition ofAvionics Concepts foraHea^UHCargoVehide 


carried out at the required level of fidelity. Just as important is the ability to precisely 
manipulate the interface characteristics. Fault insertion and off limit operation can enhance 
the thoroughness of testing. 

The GBT is modular at all functional levels so, as it develops and the support requirements 
change, the lab can add or access the required resources. This translates to the GBT being 
able to accommodate any vehicle or system simulation of similar complexity to the then 
current defined reference vehicle and systems. Modular design in both the GBTs hardware 
and software facilitate an orderly expansion of capability. The foundation of hardware model 
benchmarks will be validated against real equipment. Once proven, a combination of real 
and simulated hardware models can be utilized to evaluate any number of proposed system 
architectures. 

Since one of the GBTs primary functions is to provide timely support to new projects, it must 
have the ability to quickly adapt to the specific needs of those projects. This flexibility must be 
a basic consideration in the GBT architecture so it can perform that level of testing or 
simulation required in a more cost effective manner than currently available to new projects. 

The current implementation plan for GBT establishes an August 1990 IOC to support Shuttle- 
C, (figure 1.2-2). In actuality, the GBT will have more than half of its total planned capability at 
this point. The software tools and models developed for the Shuttle-C are basically generic 
in nature, with separate data files supplying the unique values for this vehicle, its subsystems, 
and mission profiles. In most cases, only data set value changes would be required to switch 
from one vehicle configuration to another. 


3.0 TRADE STUDIES AND TECHNICAL ANALYSIS 

Several technical issues had to be resolved prior to the definition of the three HLCV avionic 
system designs and the Ground Based Test Bed. 

The range of studies originally considered covered the three HLCV reference vehicles and 
the GBT. Those chosen for further study included: 

• RVU replacement of EIU 

• Vehicle Processors 

• Software Language and Tool selection 

• Flight Control Actuators 

• Vehicle Power 

• Lab Architecture 

• Data Buses and High Speed Networks 


3.1 ENGINE INTERFACE UNIT REPLACEMENT 

The feasibility of replacing the current Space Shuttle Main Engine (SSME) EIU with a 
modified Remote Voter Unit (RVU II) was investigated for the SDV-2ES (Shuttle C). Figure 
3.1-1 summarizes the results. Though future plans point to simpler engine control 
requirements, the current assumptions, of a total functional replacement for the SSME EIU 
didn't prove to be economically feasible. Section 3 of Volume 2 contains the details of this 
study. Notable, however, is that this study lead to investigation of RVU replacement of the 
Orbiter MDMs and RJD in the SDV-2ES avionics system. This in turn lead to the Shuttle C 
Option C avionics configuration. The Concept Definition Section of Volume 2 contains this 
design. 
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FIGURE 3.1-1. RVU ll-EIU TRADE STUDY RESULTS 

3.2 VEHICLE PROCESSORS 


Selection of the best current CPU for the HLCV centered about the 16 bit, 1750 processors. 
Figure 3.2-1 shows the units investigated. The PSC 1750A was selected. 32 bit processors 
were also considered for far term application. 
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3.3 COMPUTER LANGUAGES 

Nine criteria were examined in selection of the software language to be used in the GBT, 
Vehicle, and ground Checkout facilities. Figure 3.3-1 summarizes these results. Ada was 
chosen with "C" selected for use in special test equipment and small simulations until 
software and tools become available in Ada. 
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FIGURE 3.3-1. TECHNOLOGY MATRIX - COMPUTER LANGUAGES 


3.4 FLIGHT CONTROL ACTUATORS 

The large Thrust Vector Control, (TVC) actuators proved to be the major area of concern in 
the developing area of Flight Control Actuators. Mid and Far Term vehicles will employ 
significantly more engines. The five primary ascent engines of the Shuttle will give way to 
clustered engine configurations using 14 to 20 engines on some future applications. The 
impact to ground processing and maintenance look to be intolerable if hydraulic actuators 
are retained. Electromechanical and Hyrostatic actuators present a better potential. Large 
EMAs, of the 50+ Horsepower range required, are still in development. Though control 
system design is adequate, development is needed in the power supply and distribution 
system areas. Figure 3.4-1 shows the three types of actuators investigated. 

Recommendations included the retention of hydraulic actuators on near-term vehicles that 
still had relatively few engines. Design provisions should be made, even on these vehicles, 
for replacement with EMAs in the future. Emphasis on EMA and ancillary system 
development was felt to be imperative in light of the potential savings in maintenance, 
production and ground operations costs. Performance gains were felt possible, particularly 
in reusable, clustered engine configurations. Here the potential weight savings and 
increases in system reliability are significant. 
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FIGURE 3.4-1. TECHNOLOGY MATRIX: ACTUATORS 


3.5 VEHICLE POWER 

The HLCV short duration missions seemed to dictate from the start that batteries rather than 
fuel cells would be the logical choice. A number of batteries were examined, along with a 
generic fuel cell, for near and far term applications. Figure 3.5-1 shows the general results. 
The analysis pointed to Lithium Thionyl Chloride as the best primary battery with Zinc Silver 
as a good back-up source. Fuel cells were shown to become more viable on long duration 
missions. 

Power Distribution System designs were also explored. High and low voltage DC systems 
were compared with AC systems whose frequencies ranged from 400Hz to 20KHz. The 
standard 28VDC system was shown adequate for near term designs. When EMAs are 
integrated into the HLCV era vehicles, a complete in depth reappraisal must be done. 

Bottom line architectural decisions emphasized a modular approach at all levels. Phase 1 
hardware includes a half filled Primary Processor, limited Avionics Hardware testbed 
capabilities and a full up G&N lab. The open architecture and modularity of the GBT permits 
an orderly upgrade of capability phase to phase. 
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FIGURE 3.5-1. TECHNOLOGY MATRIX: POWER GENERATION 


3.6 LAB ARCHITECTURE 

The GBT software and hardware architectures evolved from the functional requirements, 
GDSS base of experience and selected analysis of available hardware and software. Figure 
3.6-1 summarizes the GBT functions. The architecture must accommodate these functions in 
harmony with the GBT philosophy and objectives. 


Volume II contains a series of trades and/or analysis on each major GBT functional element. 
These analysis included a recommended level of simulation fidelity and discussed a phased 
implementation of the Target capability. Software and hardware issues were addressed. 


TEST & EVALUATION 
FEATURES 

FUNCTIONS 


INPUTS 

• SELECTABLE TEST 
ENVIRONMENT 
- Mission Phase 


• SIMULATION 

CONTROL & MONITOR 

PRODUCTS 

& 

SOLUTIONS 

\ 

- Vehicle Dynamics 

__A 

• TEST/EVALUATION 

N 

Individual Concepts \ 
Architecture Candidate^ 
Design Alternatives > 

New Applications / 

Alternate Test Methody^ 

• CONFIGURABLE 

- H/W & Systems 
Interfaces 

- Avionics System 
Simulation Testing 

| 

SIMULATION 

* DATASTORAGE 

ANALYSIS, RETRIEVAL 

Integrated Systems \ 
Selected Architecture \ 
Selected Design \ 

Approved Application / 
Selected Test Method / 

"" V 

• STAND ALONE 
- Component 
Benchmark Tests 

■ 

• TEST RESULTS 
DEMONSTRATION & 
DOCUMENTATION 
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FIGURE 3.6-1. GBT FUNCTIONS 
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3.7 DATA BUSES & HIGH SPEED NETWORKS 

Closed-loop, real time, high fidelity simulations are basic to GBT success. The proper 
selection of data bussed and high speed networks for data transfer and sharing between 
GBT elements not only required establishment of throughput but also a survey of currently 
available products. Volume II Section 2 covers this study. Figure 3.7-1 shows the four basic 
types of busses in the GBT. Phase 1 bus selection includes 1553 for the vehicle bus, Pronet 
80 for the communications and control bus and VME Bus for the DMA bus. 


FUNCTION - Simulates Vehicle Systems and Maintenance Bus Traffic/Operations 

• 1553 - 1 MBS 

• 1773 FIBER-OPTIC - 1 MB/S 

• FUTURE BUSSES- HSDB , ETC 50 MB/s 


IliiiiRlli 


•INSTRUMENTATION BUS 


FUNCTION - Simulates Vehicle Instrumentation and Sensor Busses 
* Speed - 1-100 MB/S 


III II 111 III 

gill lafflMMitCTaiiiia ii ii g g 

1111 

iniinii 

111 

111 


FUNCTION - Data Transfer and Simulation Control 
• Speed - 80 MB/S 


c 


HIGH SPEED/ DMA BUS 


FUNCTION - Processor to Processor Data Sharing 
• Speed - Processor Dependent (2.5 GB/s - Butterfly) 


3 


FIGURE 3.7-1. GBL BUS CLASSIFICATIONS 


3.8 GBT MAIN PROCESSOR TECHNICAL DEMONSTRATION 

With the shift of emphasis to design of the GBT, selection of the primary lab processor took on 
added importance. The scope of the trade study used to determine the performance 
characteristics of this unit and the attendant survey of potential vendors required a special 
effort. A technical demonstration was conceived that would permit a performance 
comparison of those processors and their software tools thought capable of fulfilling the basic 
requirements. The test would involve tasks similar to those planned for the GBT and use 
programs supplied by both the customer and GDSS. 

The initial selection process of potential processors considered about 20 candidates. Figure 
3.8-1 shows some of the selection criteria and the candidates that fulfilled the criteria. The 
"paper study" was followed up with a hand-to-hand performance comparison. Three 
benchmarks were selected to evaluate the processors and their attendant software tools. 

The first benchmark was from MSFC and was a mature Fortran coded model of the SSME. 
The second was provided by GDSS and was a modular model of the ALS avionics system 
coded in "C”. The third benchmarks were industry standards chosen by the participants. 

The final phase of the tech demo has been extended to include two additional processors for 
evaluation. Current results are found in Volume II Section 5. 
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4.0 GBT FUNCTIONAL REQUIREMENTS 

The requirements to which the GBT must respond fall into three general categories: Program 
driven requirements include such things as vehicle dynamics, mission profile/timelines and 
vehicle avionic system architecture. The second general category, Technology driven 
requirements, include design problem areas that are not meeting performance criteria or are 
limiting system efficiency or upgrade. The last general category of functional requirements is 
Facility/Resource driven requirements. These requirements are related more to the physical 
aspects of the test facility itself and the limitations of the resource equipment used in testing. 

4.1 PROGRAM DRIVEN REQUIREMENTS 

The GBT was conceived to provide support to new vehicle/spacecraft programs primarily 
before their respective Preliminary Design Reviews, (PDRs), or when the nature of the 
required support was beyond the capabilities of their local, dedicated facilities. Figure 4.1-1 
outlines some of the requirements associated with these vehicles and their mission profiles. 
Figure 4.1-2 highlights some of the program driven issues to be discussed in later sections. 

4.1.1 PHASE 1 (STV, SHUTTLE C, SDV 2ES) 
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The HLCV expendable booster, (SDV-2ES), Shuttle-C, and Space Transfer Vehicle 
developmental programs are the basis for the Phase 1 GBT functional requirements. As was 
shown in Figure 1.2-2, the Initial Operational Capability, (IOC), of the GBT is currently set for 
August 1990. The Shuttle-C was agreed upon to serve as the forcing function for the Phase 
1 lab. The functional block diagram for this three-string avionics system is shown in Figure 
4.1. 1-1. 


Vehicle 

Shuttle C 

ALS Core 

ALS LRB 

FRWB 

Reusability 

SRB’s 

None 

BRM 

Full Reuse 



T555 

1998 

T553 

l ~” 2TO2 

Engines 

3+2SR8 

3 

7 

6+6 A/B 


rro 

j - 0.9998 i ~ 

0.99995 j 

* — TBD 

1 

Cargo carrier 
Prox OPS & De -orbit 

Deorbit to ocean. 
FO/FS Manned Cargo 

Sub-orbital 
FO/FS Manned Cargo 

Return & Landing 
FO/FS Manned Cargo 

Max Mission 


Core de-orbit 


Less than 

Duration 

■ 

T + 98 min. 


1 hour 

Mission/Year 

Few 

Many 

Many 

Many 


Moderate 

Many 

Many 

Few 


Separate LPS, GSE 
Prod C/O 

UNIS for Integrated 
Data 

UNIS 

UNIS 

Launch Processing 

LPS 

Expert System App 

Expert Systems App. 

Near Autonomous 

■snKrmwasiKiEinaEB 

■EliEQlIDUEIlIiliSiESSSi 

None 

None 

None 


Central computers O.S 

Mission manager 

Controlled from 

Near Autonomous 

Management 

Command Uplink 

Expert Systems 

Core 


Rendezvous & 
Docking 

OMV Assisted 

None 

None 

None 

Data Flow 


GN&C 3 - <1 MBPS 
Instru 1 - 256 KBPS 

Interface to 
Core 

GN&C 3 - <10 MBPS 
Instru 1 - 320 KBPS 

Processing 

300 KOPS 

GN&C 3 - 3 MIPS 
Propulsion 3 - 1 MIPS 
Instru 1 - 3 MIPS 

Share core GN&C 
Propulsion 7-1 MIPS 
Share core Instru 

GN&C 3 -6 MIPS 
Propulsion 6 - 1 MIPS 
Instru 1 - 3 MIPS 


Miscellaneous < 1 MIPS 

Miscellaneous <1 MIPS 

Imaging 10 MIPS 
Miscellaneous <2 MIPS 


FIGURE 4.1-1 HLCV AVIONICS REQUIREMENTS 


Its accompanying Design Reference Missions (DRMs), are shown in Figure 5. 1.1 -2 These 
DRMs must be considered when building the software environmental and vehicle models. 


4.1.2 PHASE 2 (ALS CORE, ALS BOOSTER, SDV 2RS) 

The Phase 2 IOC is set for August 1992. The Phase 2 GBT support capabilities will be 
extended to include the ALS Core and Booster, SDV-2RS, and the upgraded Shuttle-C. 
Since the ALS Core and Booster closely fit the SDV-2RS functional requirements, they were 
chosen for the reference vehicles for the Phase 2 GBT. Figure 4. 1.2-1 through 4. 1.2-3 show 
the ALS Core and Booster avionics systems and the associated vehicle processing 
requirements. Figure 4. 1.2-4 associates the ALS Core throughput requirements with its 
design reference mission timeline. 
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• VEHICLES 

- PERFORM AVIONICS ANALYSIS/SIMULATION TO VERIFY RE-TEST AND RE-USE 
CAPABILITY OF FRWB AND BRM MULTI-MISSION AVIONICS 

• LAUNCH PROCESSING AND VEHICLE MANAGEMENT 

- PROVIDE THE PROCESSING THROUGHPUT AND MEMORY CAPACITY FOR EXPERT 
SYSTEM APPLICATION DEVELOPMENT OF BOTH LAUNCH PROCESSING AND ON-BOARD 

MISSION MANAGER 
'• RENDEZVOUS AND DOCKING 

- PROVIDE A 3D DISPLAY PROCESSING CAPABILITY FOR SHUTTLE C CARGO CARRIER/ 
OMV/ SPACE STATION. PROVIDE A FUTURE CAPABILITY IF ALS CORE DEVELOPS 
THIS TYPE OF MISSION 

. IOC 

- 1994 SHUTTLE C PROVIDE PROVISIONS FOR SIMULATING MODIFICATIONS TO 
EXISTING HARDWARE AND SOFTWARE 

• 1997 ALS REQUIRES EXPENDABLE CAPABILITY AS ALS SOFTWARE IS EXPANDED 

- 2000 FRWB WIDE CAPABILITY 

• MAN RATING 

- SHUTTLE C CARGO CARRIER FO/FS FOR SPACE STATION PROXIMITY OPERATIONS. 
DIFFERENT CARGO CARRIER FOR INJECTION MISSIONS? 

- ALS CORE FO FOR DE-ORBIT, FO/FS FOR MANNED CARGO 

- FRWB FO/FS FOR FLYBACK AND LANDING. FO/FS FOR MANNED CARGO 

- HLCV GBT SIMULATE REDUNDANCY PROVISIONS TO MEET ABOVE GOALS 

• ENGINE SYSTEM INTEGRATION 

- 3 SHUTTLE C, 10 TO 14 ALS FUTURE SYSTEMS 

- TVC ENGINE CONTROL INTEGRATION (-1 MIPS PER ENGINE) 

- SIMULATE ARCHITECTURE PARTITIONING FOR BRM RECOVERABLE AVIONICS 



FIGURE 4.1. 1-1. GBT PHASE 1 SHUTTLE-C AVIONICS BASELINE 
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DISCRIMINATING 

CHARACTERISTICS 

DESIGN REFERENCE MISSIONS 
(DRM'S) 

PERFORMANCE REFERENCE 
MISSIONS (PRM*S) 

(1) UNMANNED 
SPACE STATION 
ASSY W/OMV 

(2) ORBITAL 
DEPLOY 

(3) SUB- 
ORBITAL 
DEPLOY 

(1) POLAR 
LAUNCH 
FROM ETR 

(2) POLAR 
LAUNCH 
FROM WTR 

LAUNCH SITE 

ETR 

ETR 

ETR 

ETR 

WTR 

SECURE 

NO 

POSSIBLY 

POSSIBLY 

POSSIBLY 

YES 

INCLINATION 

28.5’ 

28.5’-63.5‘ 

28.5’ 

98.7* 

98.7’ 

RENDEZVOUS & PROX OPS 

YES 

NO 

NO 

NO 

NO 

REFERENCE ALTITUDE 

220 nmi 

110 nmi 

> 100 nmi 

100 nmi 

100 nmi 

DOCK/BERTH 

YES 

NO 

NO 

NO 

NO 

ON-ORBIT STAY TIME 

APPROX. 14 DAYS 

1 DAY 

UNSPECIFIED 

<2-1/2 HR 

<2-1/2 HR 

CIRCULARIZATION 

YES 

YES 

NO 

YES 

YES 

PAYLOAD DEPLOYED 

NO 

YES 

YES 

YES 

YES 

PAYLOAD EXTRACTED 

YES 

NO 

NO 

NO 

NO 

MANNED PRESENCE 

YES 

NO 

NO 

NO 

NO 

MIXED CARGO 

YES 

POSSIBLY 

NO 

POSSIBLY 

POSSIBLY 

OMV 

YES 

POSSIBLY 

NO 

NO 

NO 

MINIMUM INJECTED WEIGHT 
@ REFERENCE ALTITUDE 

100,000 LB 

80,000 LB 

100,000 LB 

TBD 

TBD 

INSERTION 

DIRECT 

STANDARD 

SUBORBITAL 

UPSPECIFIED 

UNSPECIFIED 


FIGURE 4.1. 1-2. SHUTTLE C MISSION REFERENCES 
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AVIONICS DETAILED BLOCK DIAGRAM 





FIGURE 4.1. 2-1 ALS AVIONICS & POWER SYSTEMS 


ALS CORE 



WITH LIMITED EXPERT SYSTEMS 

SUBSYSTEM (WITH 
HEALTH MONITORING) 

THRUPUT 

(MIPS) 

TOTAL 

MEMORY 

(MBYTES) 

I/O 

DATA RATE 
(MBPS) 

I/O 

DEVICES 

(QUANTITY) 

PROPULSION 

3 

(IM IPS/ENG) 

0.288 

0.375 

819 

FLUIDS 

<0.1 

<0.1 

0.216 

241 

POWER 

<0.1 

<0.1 

<0.01 

100 j 

# INSTRUMENTATION 

<3 

<0.002 

0.256 

1500 

GN&C (ADAPTIVE) 

4.063 

0.988 

0.153 

600 

SYSTEMS SOFTWARE 

0.21 

0.59 

- 

•- 

COMMUNICATIONS 

<0.1 

<0.1 

<0.01 

100 

VEHICLE ELEMENT 
INTERFACE 

<0.1 

<0.1 

0.072 

262 

TOTAL 

10.47 

2.06 

1.09 

3622 

SHUTTLE 

COMPARISON 

0 343 

0.42 

NA 

-4000 


# INCLUDES SENSOR PROCESSING NOT NOTE: THE PROCESSING REQUIREMENTS 

COVERED UNDER THE OTHER SUBSYSTEMS. DO NOT INCLUDE ANY ALLOWANCE FOR 

NOTE: REDUNDANCY INCLUDED ONLY WHERE MARGIN. OB FAiUJRE TOLERANCE. (EXCEPT 
KNOWN (E G., PROPULSION) F0R PROPULSION) 


FIGURE 4.1. 2-2 ALS CORE PROCESSING REQUIREMENTS 
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ALS LRB 



WITH LIMITED EXPERT SYSTEMS 

SUBSYSTEM (WITH 
HEALTH MONITORING) 

THRUPUT 

(MIPS) 

TOTAL 

MEMORY 

(MBYTES) 

I/O 

DATA RATE 
(MBPS) 

I/O 

DEVICES 

(QUANTITY) 

PROPULSION 

7 

(IMIPS/ENG) 

0.672 

0.875 

1911 

FLUIDS 

~ 

- 

0.216 

241 

POWER 

- 

- 

<0.01 

75 

# INSTRUMENTATION 

- 

-- 

0.100 

750 

GN&C (ADAPTIVE) 

- 

- 

0.153 

300 

SYSTEMS SOFTWARE 

0.10 

0.20 

- 

- 

COMMUNICATIONS 

" 

- 

- 

- 

VEHICLE ELEMENT 
INTERFACE 

<0.1 

<0.1 

0.072 

262 

TOTAL 

7.2 

0.972 

1.426 

3539 

SHUTTLE 

COMPARISON 

0.343 

0.42 

NA 

-4000 


# INCLUDES SENSOR INTERFACING NOT 
COVERED UNDER THE OTHER SUBSYSTEMS. 

NOTE: REDUNDANCY INCLUDED ONLY WHERE 
KNOWN (E.G., PROPULSION) 


NOTE: THE PROCESSING REQUIREMENTS 
DO NOT INCLUDE ANY ALLOWANCE FOR 
MARGIN, OR FAILURE TOLERANCE. (EXCEPT 
FOR PROPULSION) 


FIGURE 4.1. 2-3 ALS LRB PROCESSING REQUIREMENTS 
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Q 
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FIGURE 4. 1.2-4 ALS THROUGH-PUT REQUIREMENTS 
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4.1.3 Target (FRWB, FRWB, PRCV) 

The Phase 3 or Target configuration IOC has not been set, but if it is tied to the Fully 
Recoverable Wing Booster (FRWB), and the Partially Reusable Cargo Vehicle (PRCV) 
programs, it should be in 1996 to 1998. 

Figure 4.1. 3-1 outlines the Processing Requirements for the FRWB while Figure 4.1. 3-2 
associates the throughput requirements with the FRWB mission timeline. The FRWB avionics 
system is designed to be fully autonomous from launch to landing and roll out. The GBTs 
capability to support FRWB and PRCV development must start long before the 1996-1998 
IOC. The GBT functions must include FRWB/PRCV related inputs in both Phase 1 and Phase 
2. Typical of these inputs are: 

(1) Electromechanical Actuator applications in vehicle aero control and Thrust Vector 
Control systems; 

(2) Redundancy Management using Expert Systems and a distributed processing system; 
and 


(3) An autonomous, robust GN&C system capable of near all-weather launches and 
minimum tailoring of software mission to mission. 


These technology driven requirements are discussed in the next section. 


FULLY REUSABLE WINGED BOOSTER (FRWB) 



WITH LI 

MITED EXPERT SYSTEMS 

SUBSYSTEM (WITH 
HEALTH MONITORING) 

THRUPUT 

(MIPS) 

TOTAL 

MEMORY 

(MBYTES) 

I/O 

DATA RATE 
(MBPS) 

I/O 

DEVICES 

(QUANTITY) 

'PROPULSION 

6 

(IMIPS/ENG) 

1.152 

06 

3254 

FLUIDS 

<0.1 

<0.1 

0.32 

380 

POWER 

<0.1 

<0.1 

<0.01 

180 

# INSTRUMENTATION 

<3 

0.0048 

0.320 

4000 

GN&C (ADAPTIVE) 

5.199 

1.264 

0.394 

1225 

SYSTEMS SOFTWARE 

0.24 

0.79 

- 

- 

COMMUNICATIONS 

<0.1 

<0.1 

<0.01 

120 

VEHICLE ELEMENT 
INTERFACE 

<0.1 

<0.1 

0.0256 

5 

TOTAL 

14.64 

3.42 

1.67 

9174 

SHUTTLE 

COMPARISON 

0.343 

0.42 

NA 

-4000 


• PROCESSING IS TIME SNARED 
BETWEEN BOOSTER ENGINES 
AND AIR BREATING ENGINES. 

# INCLUDES SENSOR PROCESSING 
NOT COVERED UNDER OTHER 
SUBSYSTEMS. 

NOTE : REDUNDANCY INCLUDED ONLY 
WHERE KNOWN (E.G., PROPULSION). 


NOTE: THE PROCESSING REQUIREMENTS 
DO NOT INCLUDE ANY ALLOWANCE FOR 
MARGIN, OR FAILURE TOLERANCE (EXCEPT 
FOR PROPULSION). 

NOTE : THE PROCESSING REQUIREMENTS DO 
NOT INCLUDE THE IMAGING SENSOR 
PECULIAR PROCESSING WHICH IS 
ASSUMED TO BE SELF CONTAINED 


FIGURE 4.1 .3-1. FRWB PROCESSING REQUIREMENTS 
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FIGURE 4.1 .3-2. FRWB THROUGH-PUT REQUIREMENTS 


4.2 TECHNOLOGY DRIVEN REQUIREMENTS 

Several pacing technologies were investigated during the initial stages of this study. Each 
was associated with their specific application on the HLCV era avionics systems and 
prioritized as to their role in achieving the design goals. The following paragraphs show the 
impact on the GBT design. 


4.2.1 SYSTEM ARCHITECTURES/REDUNDANCY MANAGEMENT 

One of the most fundamental drivers of the GBT processing/throughput requirements involves 
the basic vehicle architectures to be simulated and the operational environment in which they 
must be tested. The basic Phase 1 through the complex Target GBT configuration had to be 
sized to full-up, end-to-end, real-time vehicle system simulations. This translates into a 
throughput requirement for the lab of about 150 million instructions per second (MIPS) for the 
Phase 2 GBT. The processor assigned to model the system architecture had to be able to 
model a parallel, distributed, multi-string system; duplicate the redundancy management 
logic of that system and be able to monitor, control and provide external stimuli to the system 
under test. The FRWB avionics system is fully autonomous and, therefore, includes 
Integrated Health Monitoring (IHM), and a high precision launch to launch GN&C system that 
may incorporate a multi-spectral Image Processing System. Much of the traditional GSE 
functions will be performed by the FRWB system. All these factors will drive the GBT 
throughput and parallel processing capacity well beyond the 150 MIPS of the Phase 2 lab. 
This mandates a main processing capacity which can be expanded incrementally without 
having to replace the original equipment. 
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4.2.2 POWER DISTRIBUTION, CONDITIONING AND MANAGEMENT 

The HLCV era vehicles are required to perform over a wide ranging series of missions that 
last from 90 minutes to several months. The reliability required of the supporting power 
systems plus the new demands of cost effectiveness have driven a re-examination of 
traditional solutions and a search for new designs. The increasing demand for power by 
electromechanical actuators and the new designs being utilized in their attendant power 
supplies have elevated this once stable design area into new activity. The GBT power 
extension will be able to evaluate alternate power sources (batteries, fuel cells and solar 
cells), power distribution system architectures, redundancy management schemes, and 
different methods of power conditioning and management. 

4.2.3 ELECTRO MECHANICAL ACTUATORS 

The clustered rocket engines of many of the HLCV vehicles have accelerated development of 
fast response high power (> 50 hp) electromechanical actuators. The HLCV GBT will support 
this effort in Phase 2. Development will be in the power supply design as well as that of the 
basic actuator. 

The integration of actuator development and testing in the total vehicle development program 
involves several areas. The end-to-end testing would, in its highest fidelity mode, require the 
actuator under test to be dynamically loaded. This loading would be controlled in part by 
inputs from the missions environmental and vehicle dynamic models. The dynamic load cell 
and its attendant support equipment could represent a prohibitively high investment. Use of 
existing or dedicated actuator labs may prove the most cost effective method of providing this 
resource. A high data rate, broadband data link to the GBT could be used in closed loop 
testing. EMA power supply development could be accommodated in the GBT Power 
Systems extension. 


4.2.4 ADAPTIVE GUIDANCE, NAVIGATION & CONTROL 

HLCV traffic models force a more robust launch capability. Not only do vehicles have to be 
easy to process and launch, they must be strong enough and smart enough to handle less 
favorable environmental conditions. Supporting Adaptive Guidance, Navigation & Control 
would include everything from concept evaluation through sensor design testing. Primary 
impact of this technology support by the GBT would be in the area of software development, 
and attendant processor capacity and flexibility. Special software analysis tools will be 
required in the investigation of various load relief concepts, sensor applications and vehicle 
dynamic control modeling. 

4.2.5 IMAGE PROCESSING 

The application of image processing to HLCV functions seems particularly attractive in the 
areas of rendezvous & docking and approach & landing. The delays and subsequent risks 
involved in the remote docking techniques used in OMV can be potentially mitigated with a 
"smart" docking system. Such a system could be used on the STV or retrofitted on the OMV. 
Use of image processing to detect/identify the target, its range and orientation are well within 
current state-of-the-art capabilities. Application in the FRWB approach & landing functions is 
another application to be investigated. 
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Impact to the GBT design would include software tools required for high fidelity 3D Target 
modeling and animation. Hardware requirements would include prototype sensors, TV 
camera, large, high resolution graphic monitor and an image processing workstation. 

5.0 GBT IMPLEMENTATION PLANNING 

From the beginning, it was recognized that the Ground Based Test beds capabilities would 
be tied to meeting current program system testing requirements. The GBTs role was to 
encompass vehicle simulation and testing needs from inception to the Preliminary Design 
Review (PDR). Looking at the projected vehicle developmental schedules, it was all too clear 
that the first operational GBT capabilities would have to be focused on the critical 
developmental problems. If vehicles like the Shuttle C or STV were to be supported prior to 
their PDRs the GBT must be at least operational by August 1990. Basic avionic system 
architectural issues would have to be addressed first. The initial GBT would have to provide 
high fidelity, precision guidance & navigation simulations that supported evaluation of the 
several configurations being investigated. This dictated identification of long lead items like 
the 3-axis table. 

Software model development is another key factor in the implementation plan. Fidelity of the 
vehicle dynamic and system models is critical to establishing the GBT as a valuable program 
development resource. This usually requires actual hardware being used to develop and 
verify the fidelity of the respective software models. Availability of similar hardware often 
proves to be another pacing element. 

Accelerating the application of new, useful technologies into current and future programs was 
another stated goal of the GBT. To this point, all the GBT capabilities were directed at 
specific problems of specific programs because of time related and money related 
constraints. The implementation plan has evolved to the point that permits visibility as to how 
this goal can be realized. First, the basic GBT hardware and software design is modular and 
thus can be changed easily to accommodate different requirements. The early phases of 
implementation require the building of a specific number of these basic modules to satisfy a 
limited number of needs. To satisfy a greater set of requirements relatively few new modules 
are required. 

Figure 5.0-1 shows an early implementation schedule and its assumptions. One of the most 
difficult problems of the implementation schedule, shown earlier in figure 1.2-2, is the amount 
of work to be done in the first phase. Between February 1989 and August 1990, over 60% of 
the total task must be accomplished. This is not consist with the relatively low front end 
funding guidelines that were provided for this study. Figure 5.0-2 shows this problem 
graphically. 

The bottom line for GBT success is being able to supply the most cost effective and useful test 
facility at the time when new programs need it the most. This implies that the projects are 
willing to pay their way and plan for such usage initially. This idealistic form of funding must 
be recognized as supplemental to basic level of funding needed to initially implement and 
later maintain GBT operations. Internal Research & Development projects are also a source 
of funding. This type of function typically accelerates the application of useful, new 
technologies and test concepts upon which later major programs are built. 
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LAB PRELIMINARY IMPLEMENTATION SCHEDULE 


1989 | 1 990 I 1991 I 1992 i 1993 


1994 


1 995) 


HLCV Related Mileetonee 
• SDV-2ES IOC 1993 
•SDV-2RS IOC 1993 
•FRWB IOC 1998-2000+ 
•PRCV IOC 1998-2000+ 
SHUTTLE C IOC 1994 
ALS IOC 1996-98 

Upper Stages 

•OTV IOC TBO 

•AOTV IOC TBO 

INITIAL Lab MileSlonee 
•Procurement 
•S/W Development 
•H/W Design A Fab 
•Fit HM Acq 
•Facility Prep 
•Lab Activation 


RFP 


Start 


|ALS Ppase 3 
tart 


LAB IOC 


Evcf 


PDF 


ution jor Do\|i 


COR 


n stream IOC 


PF On 


Pad 


IOC 


Lab Program Drivers 

• 4 Year Development Cycle 

• IOC First Launch. Delivery to pad 1 year prior to Launch. 

• Full Scale Engineering Development Systems Integration Laboratory with Pathfinder Activity 

• A PC Supports Early PDRs 


FIGURE 5.0-1. IMPLEMENTATION PLAN 



6.0 GBT ARCHITECTURE 
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This section covers both the hardware and software architectures of the GBT. It should be 
noted that the GBT has been structured to allow for a phased implementation of capabilities. 
The Target GBT is the full-up, third step configuration. It was designed to support the third 
HLCV reference configuration. This Fly Back Booster and Partially Reusable Cargo Vehicle 
must be accommodated in the Target GBT end-to-end real-time simulation. 

6.1 HARDWARE CONFIGURATIONS 


6.1.1 GBT TARGET CONFIGURATION 

The GBT Target Configuration is shown in figure 6. 1.1-1. The GBT core has a main 
processor which is functionally divided into the primary processor and the avionics system 
simulator. 

The primary processor function includes running the simulation of the test vehicle dynamics, 
the mission environment and all other interfacing elements to the vehicle avionics system. 

The avionics system simulation function includes running the simulation of the test vehicle 
avionics system. This includes the monitor and control of all interfaces to real hardware 
being tested or run on the Avionics Hardware Test Bench. 



FIGURE 6. 1.1-1. GBT TARGET CONFIGURATION 


OF POOR QUALITY 
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REQUIREMENT: 150 MIPS - For Real Time simulation of HLCV era vehicles 

BASIS: EXTRAPOLATION FROM CURRENT SIMULATION 

• 6 DOF Flight Trajectory Simulation 

• 96 state variables 

• 20 millisecond Autopilot cycle 

• X10-20 Intercycle 

• 2 NASTRAN modes, Bending mode 

• Autopilot functions, bending modes, distributed aerodynamics, mass 
distribution updating 

• Apollo 3000 Workstation runs non-real time simulation In 10 hours. Real 
time: 270 seconds (Real time speed up: 133X for Identical task) 

• Increased Scope of Simulation 

• Add 4 rate gyros 

• Distributed Accelerometers 

• Air data sensors 

• X5 propulsion system interface 

• Adaptive guidance 

• Autoland 

» Increase for Growth 


FIGURE 6.1-2. CORE PROCESSOR THROUGH-PUT SIZING ENVIRONMENT/VEHICLE 

DYNAMICS 

Core Processing throughput sizing is shown in figure 6. 1.1 -2. This estimate of processor 
power and speed was made by extrapolation from a current simulation. A second method 
based upon sensor input and other system operational parameters came up with a slightly 
higher figure. An analysis of the scope and nature of the simulation required to yield an end- 
to-end, real-time simulation of the FRWB and PRCV indicated a minimum rating for the 
primary processor should be 150 MIPS. Prudent design practice would require a modular 
architecture in which the processor could be scaled-up to meet the job. 

The four other main elements of the GBT core are the Main Control Processor, Mass Storage 
Unit, Hard Copy Processor and Interconnecting network/buss structure. The Main Control 
Processor is primarily tasked with the allocation and control of GBT resources. It controls 
most of the various busses and networks running throughout the GBT and supervises use of 
the Mass Storage and Hard copy Processor. 

The Mass Storage units permits rapid access to the application, development, test and 
custom software/data. The Hard Copy Processors provide hard copy records of screen 
displays, system status, or test results. 

The Avionics Hardware Test Bed is the second major segment of the GBT Target 
Configuration. It contains the interfacing units, busses and harnesses necessary to 
accommodate the GBT Benchmark hardware. The benchmark hardware is a collection of 
current avionics units which, when connected to the required interfacing harness, comprise a 
fully functional avionics system. 


The Instrumentation segment is a subset of the Avionics hardware test bed that permits local 
control and monitoring of the test bed hardware or units under test. It functionally duplicities 
an instrumentation ground station and is equipped to analyze vehicle bus traffic. 
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The GBT Display Center electronic equipment is shown in part in figure 6. 1.1-1. It primarily 
consists of four graphics processors driving four large screen monitors. The graphics 
processors are used to develop display and other support type graphics. Working with the 
large screen monitors, the processors can reproduce demonstration graphics depicting 
anything from real-time test parameters to reproduction of demonstration graphics. These 
monitors may be used to supplement the status displays available to the core's main control 
processor. The graphics processors will also supplement the Main Control Processor in 
controlling parallel operations going on within the GBT. . 

The G&N Lab is one of the most important resources available to the GBT. Though capable 
of fully independent operation, in an acceptance test procedure role, its primary value is in 
closed-loop simulation of an integrated avionics system. The precision 3-axis table can 
supply all necessary stimuli, except acceleration, to evaluate the best inertial elements of the 
HLCV era. The Slave I/O interface box will provide the local real-time interfaces to 
accommodate such testing. 


6.1.2 PHASE 1 CONFIGURATION 

The initial Phase 1 GBT configuration is scheduled to be operable in August of 1990. Figure 
6.1. 2-1 lists several of the support capabilities to be demonstrated at that time. SDV-2ES is 
the first HLCV reference vehicle and functionally equivalent to Shuttle-C. Its mission profile is 
depicted in figure 6.1 .2-2. Four software mission phase models are required for the Phase 1 
IOC. They include Launch, Ascent, Orbital maneuvering and a ballistic type of controlled 
entry. 

Benchmark hardware includes the equivalent of 1 string of the Shuttle-Derived Vehicle 
avionics system. Limited interface capabilities on the Avionics hardware testbed can accom- 
modate only two "boxes". (This capability will be expanded substantially during Phase 2). 


MISSION MODELS - (2DV-2ES) 

• Launch 

• Ascent 

• On Orbit (maneuver) 

• Entry 

SYSTEM TEST 

• SDV Reference System 
IMU 

Computer 
DAS 
MDU 
RDU 

MDM * Interface only 
EIU * Interface only 

OUTSIDE RESOURCES 

• SSME Lab Interface 

« EMA (option) 


FIGURE 6.1. 2-1. PHASE 1 CAPABILITIES AND CONSTRAINTS 
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FIGURE 6.1. 2-2. MISSION PROFILE 



INCLUDES HEALTH MONITORING. 
INCLUDES REDUNDANCY WHERE KNOWN. 
NO MARGIN ALLOWANCE. 



LCEE 

SHUTOFF 


PAYLOAD 

SEPARATION 


END OF 
MISSION 


FIGURE 6.1. 2-3. PHASE 1 VEHICLE PROCESSING TIMELINE 
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Figure 6.1 .2-3 shows a vehicle processing throughput as a function of time. These projected 
through-put levels added to the requirements for vehicle dynamics and mission environment 
require the core processor to equal or exceed its projected 70+ MIPS configuration for Phase 
1. 

Flight operations for Shuttle-C, shown in figure 6. 1.2-4 were used in projecting the 
throughput requirements. 

The Phase 1 GBT Configuration is pictured in figure 6.1. 2-5. Many target capabilities are 
absent. Among these are the interface provisions to many of the resource labs and 
extensions. The G&N Lab is the exception where a full link is present. The Propulsion Lab 
also will have a port available on the fiber optic communications and control bus. 

• AUTONOMOUS FLIGHT CONTROL TO ORBITAL INSERTION, CIRCULIZATION 
AND DEORBIT 

• Simplex Shuttle-C mission control center 

• Basic Shuttle-C avionics for this function 

• Precursor mission planning (simplex), payload integration to cargo bay by 
Shuttle-C 

• ORBITAL DEPLOY MISSIONS (E.G., PLANETARY AND OTHER FREE FLYING 
SPACECRAFT 

• Payload developer responsible for operations from POCC after payload 
separation 

• SPACE STATION MISSIONS 

• PrecUYsor mission (A on orbit) planning done as part of OMV/SS activity 

• OMV/Space Station control center responsible for rendezvous, Prox-ops, 
docking, mission operations (e.g., assembly) and deorbit from SS/OMV 
control center or multi-purpose control center 

; » Very limited "kit on'* Shuttle-C delta avionics Including batteries, etc. 


FIGURE 6. 1.2-4. FLIGHT OPERATIONS 

The GBT Core Processor is only partially filled, giving it a throughput of about 70+ MIPS. The 
software will be developed initially on the Graphic Processors residing in the display center. 
The function of the display/demo center and software development will be performed at that 
location. The benchmark hardware used in the avionics hardware testbed will probably be a 
single string of the Shuttle-C architecture. The interfacing capabilities of the Master I/O unit 
will accommodate only the equivalent of an Inertial Navigation Unit (INU) and a Remote 
Voting Unit (RVU) simultaneously. 
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GBT PHASE 1 CONFIGURATION 




flylrtma I iaitoti 







Primary 

Processor 


Avionics 

System 

Simulator 


Ep^I] 

n^-M 



Engine Interface Unit 
InertiaJ Navigation Unit I 
Master Data Unit 
Puts# Code Modulaton j 
Power Distrfeution Unit | 
Remote Data Unit 
Remote Voting Unit 


FIGURE 6.1. 2-5 GBT PHASE 1 CONFIGURATION 


6.1.3 PHASE 2 CONFIGURATION 

The Phase 2 GBT capabilities and constraints are listed in figure 6.1 .3-1 . Vehicle simulation 
capabilities now include the ALS Booster and Core. The overall simulation capability is more 
generic than before, with the complete range of software modules completed. The Core 
Processor has been fully expanded to the target configuration, permitting complete end-to- 
end, real-time simulations. Rendezvous and Docking and Precision Entry simulations will 
also be possible in Phase 2. 

Hardware testing of a complete "string" of avionics equipment will be possible with the 
avionics hardware test bench. A more complete set of generic software models will be 
available for use. 

Figure 6.1 .3-2 depicts the Phase 2 GBT configuration. Note the changes in the hardware test 
bed and display center. Now a separate software development facility is available and links 
are available to a variety of labs and extensions. 
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1 . MISSION MODELS - Shuttle-C, ALS, (-Generic) 

• Launch 

• Ascent 

• On Orbit (STV) Maneuver, Rendezvous & Docking 

• Entry (Controlled and precision) 

2. SYSTEM TEST - Shuttle-C, ALS, STV (-Generic) 

• G/Ns 

• F/CS 

• F/CP 

• DAS 

• PC 

• S/SC 

3. OUTSIDE RESOURCES 

• SSME Lab Interface 

» Actuator Lab 

FIGURE 6.1. 3-1. PHASE II CAPABILITIES/CONSTRAINTS 
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Engine Interface Unit 

INU 

Inertial Navigation Unit 

MOU 

Master Data Unit 

PCM 

Pulse Code Modulation 

POU 

Power Distribution Unit 

ROU 

Remote Data Unit 

RVU 

Remote Voting Unit 
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FIGURE 6.1. 3-2. GBT PHASE II CONFIGURATION 
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7.0 HLCV GROUND BASED TESTBED FACILITIES 

The detailed facility requirements for each major GBT element are contained in the 
Preliminary Design Document, (PDD). These requirements cover the basic power, space 
and environmental needs of the major GBT elements but don't address the overall Lab 
layout. This section will summarize the recommendations from which the layout will be 
determined. Fuller definition of the layout was deferred pending definition of the actual GBT 
site and the modification possible with the funds allotted. 


7.1 LOCATION 

Key to the utility of the Ground Based Testbed is its proximity to the resources it 
must draw upon and serve. Early utilization will be enhanced if it is close to exhausting 
testing facilities. As the GBT primary processor and attendant communication networks are 
brought onto line, closed loop simulations, involving one or more adjacent labs will become 
possible. Early attention to those existing laboratory resources that would most befit from the 
added GBT capabilities should be a factor in selecting the GBT location. 

A second factor involves the GBTs potential to become an effective and convenient 
demonstration facility. This potential will obviously be enhanced if the GBT is in close 
proximity to the existing conference and administrative sites. Figure 7.1-1 shows the 
candidate GBT site and the adjacent test and administrative facilities. 



PROPOSED GBT SITE 
• Bldg 4476 (OMV 


NEAR-BY POTENTIAL RESOURCES 

• Bldg 4487 

- AFE 3-Axl* Tab!* 

- Sky I ab 3-Ax1$ Tabl* 

• Bldg 4436 

- SSME HSL 



FIGURE 7.1-1. GBT FACILITY LOCATION 


7.2 GBT LAYOUT 
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Figure 7.2-1 shows the basic Building 4476 1st floor plan. The area designated for the GBT 
is shown in figure 7.2-2. 



FIGURE 7.2-1. BUILDING 4476, MSFC, FIRST FLOOR 



FIGURE 7.2-2. DESIGNATED GBT AREA, MSFC BUILDING 4476, FIRST FLOOR 


A change to this area is already in work, but the completion dates do not support the current 
Phase 1 IOC date of August 1990. This proposed change has three options. The "A" option 
was used in this study. 
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A general GBT layout is shown in Figure 7.2-3. Detailed layouts of existing labs at GDSS 
were used as a basis for this preliminary plan. Volume II contains these layouts and a list of 
the "lessons learned" during their implementation and use. 



7.2.1 MSFC BLD 4476 OPTION A MODIFICATIONS 

These modifications can be summarized as: 

1. Removal of Centrifuge and other obsolete structure & equipment. 

2. Extend portion of the South wall to enclose weather enclosure. 

3. Relocate South Main Entrance and enclose old entry area 

4. Remodel and enlarge 2nd floor Mezzanine area. 

5. Add Hydraulic pump room. 

6. Add Women's Restroom. 

7.2.2 PROPOSED GBT FACILITY MODIFICATIONS 

Some modifications to Building 4476 in addition to those currently being considered in 
Option A are recommended. Figure 7.2-3 contains several views of the modifications. Table 
7.2. 2-1 outlines these modifications and summarizes their basic rationales. 
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TABLE 7. 2. 2-1 


NO DESCRIPTION 

RATIONALE 

1 Southern High Bay Extension 

1 . Provides access to High Bay and 

with 2 large access doors. 

staging areas #1 & #2. 

2. Northern G&N Lab Extension 

2 . Accommodates G&N labs & provides 
North Star LOS. Provides easiest 
method to provide isolation pads for 
3 axis table. 

3. Northern High Bay Extension 

3. Accommodates future "flow through" 
processing of modules & staging. 

4. Mezzanine Modification 

4 . Optimizes main processor areas to 
resources (shortens distance to Hot 
Bench & staging areas by placing main 
processor on mezzanine. 


7.2.3 PROPOSED GBT SPACE ALLOCATION 

The original Target GBT floor plan approached 10000 square feet and featured a two story 
layout. The candidate site offered about one third of the space unmodified. Optional add-ons 
bring the usable space to around 5000 square feet and optimizes the usefulness of the 2nd 
floor area. 


7. 2. 3.1 DEMONSTRATION, CONTROL & PROCESSING CENTERS 

Figure 7.2.3.1-1 shows a general spatial allocation of the mezzanine. The GBT Primary 
Processor, Control Processor, Mass memory and hard copy printing devices will be housed 
in the GBT Processing Center upstairs and adjacent to the Demonstration & Control Center. 
Both areas will have independently controllable environments designed to properly 
accommodate the data processing equipment, staff and visitors. Attention will be given to 
provide a view of high bay and staging area operations. Windowed partitions will be utilized 
to provide the designed view of the Processing Center and downstairs working areas while 
maintaining the controlled equipment. The Demonstration area will accommodate up to 20 
visitors in a design which permits a good view of the large screen monitors, projection 
screens and main control console. Individual control of the Demonstration Center 
temperature and lighting is imperative. 

Safety provisions for rapid egress from the mezzanine require two stairways. Provisions to 
protect the Primary Processing Center from fire and intrusion should be provided. A Halon 
system should be investigated. 
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■ 50* 0V 
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FIGURE 7.2.3.1-1 MEZZANINE LAYOUT 


7. 2.3. 2 AVIONICS HARDWARE TESTBED (HOT BENCH) AND STAGING AREA 

Basic to the design of the GBT is its capability to evaluate candidate hardware in a closed- 
loop, simulated operational environment. The Target configuration will have the ability to 
interface with prototype hardware at both the box and system level. A Primary full capability 
test bed will be supplemented with staging area equipment capable of preliminary open loop 
and closed loop testing. The staging areas will enable a parallel and more efficient use of 
the GBT facilities. The large roll up type of doors will facilitate easy access to the two staging 
area test stations. The staging areas are adjacent to the upstairs processing facilities as well 
as electrical and hydraulic power sources. The space allocated for the Hardware Testbed 
and staging areas was sized to accommodate a prototype flight segment of 15 ft. diameter 
and 15 ft. height. 


7. 2. 3. 3 GUIDANCE & NAVIGATION 

Several requirements drove the location and configuration of this GBT resource lab. The 
future configuration of this lab called for dual 3-axis tables. The 10x25x10 foot isolation pad 
accommodates these units and the associated optical alignment equipment. The size of the 
pad and the ability to have a line-of-sight access to the North Star for alignment dictates the 
location within an addition on the north side of Bldg. 4476. 

7. 2.3.4 PLACEMENT OF OTHER GBT RESOURCES 

Due to the fluid nature of the already planned facility modifications and the August 1990 
Phase i IOC, specific placement of the other GBT resources is felt to be premature. 
Temporary facilities will have to be provided while Bldg. 4476 is being modified. 
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8.0 GROUND BASED LAB PHASE 1 COST ESTIMATES 

Table 8.0.-1 gives the ROM costs associated with the Phase 1 GBT. Note that these costs do 
not reflect any fees or expenses associated with procurement. The hardware and software 
prices are "list prices". Software development costs reflect only a flat hourly cost. 
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TABLE 8.0-1 PHASE 1 GBT COSTS 


9.0 SUMMARY AND CONCLUSIONS 

The purpose in defining the philosophy, objectives and desired functional capabilities of the 
Ground Based Testbed was, of course, to provide a basis for implementation planning. 
Successful implementation will be judged upon the GBTs ability to provide timely and cost 
effective support to Shuttle C, STV and other emerging programs. Figure 9.0-1 reviews the 
basic functions provided by the GBT. The other factor which can not be neglected is funding 
for the implementation and operation of the GBT. All of these factors will be summarized in 
this section. ORIGINAL IS 

OF POOR QUALITY 
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FIGURE 9.0-1 GBT FUNCTIONS 


9.1 GBT FUNCTIONAL DESIGN 

To perform the Functions and provide the Test and Evaluation Features shown, the GBT 
design evolved into several functional elements. These elements in turn were sized to 
support specific program driven capabilities and requirements. The development of element 
capabilities was paced by projected funding levels and prioritized program support 
requirements. Where possible, provisions were made to use existing, related test and 
evaluation resources. These provisions, in most cases, not only provide an earlier 
operational capability, but also extend the original resources capabilities and effectively 
extend its operational life. 

The primary functional elements of the GBT are shown in Figure 9.1-1 and will be 
discussed in the following paragraphs. 


9.1.1 GBT CORE 

The GBT has been described as spanning the test continuum from pure simulation to 
hardware performance evaluation. Common to each extreme is a flexible, high through-put 
core processor.The GBT core has a main processor which is functionally divided into the 
primary processor and the avionics system simulator. The primary processor function 
includes running the simulation of the test vehicle dynamics, the mission environment and all 
other interfacing elements to the vehicle avionics system. The avionics system simulation 
function includes running the simulation of the test vehicle avionics system. This includes the 
monitor and control of all interfaces to real hardware being tested or run on the Avionics 
Hardware Test Bench. 


Selection of this processor was one of the most important and far reaching design decisions 
of the study. The unit chosen combined an excellent cost to performance ratio with a 
software and hardware migration path capable of supporting the rapidly expanding 
simulation demands of the immediate future. Initially sized with a through put in excess of 
150 Million Instructions per Second, (MIPS), this expandable core processor has the 
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software tools and I/O ports to support the GBTs current and future Real-Time simulation 
requirements. 


The four other main elements of the GBT core are the Main Control Processor, Mass Storage 
Unit, Hard Copy Processor and Interconnecting network/buss structure. The Main Control 
Processor is primarily tasked with the allocation and control of GBT resources. It controls 
most of the various busses and networks running throughout the GBT and supervises use of 
the Mass Storage and Hard copy Processor. While functionally a part of the GBT Core, the 
Main Control Processor will probably reside in the Main Control and Demonstration center. 
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FIGURE 9.1-1 GROUND BASED TESTBED TARGET CONFIGURATION 


9.1.2 MAIN CONTROL & DEMONSTRATION CENTER 

Within this element rests the primary control and allocation of all the GBT resources. Central 
to its function is the Main Control Processor that is linked to all the available resources by an 
extensive inter / intra lab communications network. The Main Control Center and 
Demonstration Center are collocated because of their complementary functions. The 
Demonstration monitors may be used to supplement the status displays available to the 
core's Main Control Processor. The graphics processors will also supplement the Main 
Control Processor in controlling parallel operations going on within the GBT. 

The Demonstration Center primarily consists of four graphics processors driving four large 
screen monitors. The graphics processors are used to develop display and other support 
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type graphics. Working with the large screen monitors, the processors can reproduce 
demonstration graphics depicting anything from real-time test parameters to reproduction of 
demonstration graphics. 


9.1.3 AVIONICS HARDWARE TEST BED 

The Avionics Hardware Test Bed is the third major segment of the GBT Target Configuration. 
It contains the interfacing units, busses and harnesses necessary to accommodate the GBT 
Benchmark hardware. The benchmark hardware is a collection of current avionics units 
which, when connected to the required interfacing harness, comprise a fully functional 
avionics system.lt provides a real world performance standard to which the candidate 
hardware can be compared. The Avionics Hardware Test Bed therefor facilitates 
development and evaluation of new avionics systems, and components by providing a high 
fidelity, native environment in which they can be tested. 


9.1.4 GUIDANCE & NAVIGATION RESOURCE LAB 

The G&N Lab is one of the most important resources available to the GBT. Though capable 
of fully independent operation, in an acceptance test procedure role, its primary value is in 
closed-loop simulation of an integrated avionics system. The precision 3-axis table can 
supply all necessary stimuli, except acceleration, to evaluate the best inertial elements of the 
HLCV era. The Slave I/O interface box will provide the local real-time interfaces to 
accommodate such testing. 


9.1.5 INSTRUMENTATION RESOURCE LAB 

The Instrumentation segment is a subset of the Avionics hardware test bed that permits local 
control and monitoring of the test bed hardware or units under test. It functionally duplicities 
an instrumentation ground station and is equipped to analyze vehicle bus traffic. 

9.1.6 SOFTWARE DEVELOPMENT FACILITY 

A major design driver is the architecture of the user friendly software that yielded the efficient 
and highly compatible interface for potential users. The cost effectiveness of GBT usage 
rests squarely on its accessibility and its ability to accommodate several tasks in parallel. 

This translates to a modular set of software tools, tailorable to specific applications and 
executed with data that bounds the required performance regimes. The tailoring and 
selection of appropriate performance data is accomplished by a menu driven linkage 
process.The Software Development Facility will initially be located in the Main Control and 
Demonstration Facility while the basic GBT operational and benchmark software is being 
integrated. As the GBT phases into operation, the function of this element will shift to the 
primary user interface. It will become the site where users will assemble the modularized 
software tools and simulations into the desired testing regimes. The Software Development 
Facility will also host the building of the demonstration graphics. 


9.1.7 NAVIGATION AID & IMAGE PROCESSING EXTENSION 
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This GBT extension is scheduled for Phase 2 implementation. It is designed to provide 
developmental support for the autonomous rendezvous and docking aids in the near term 
and approach and landing systems for the far term Fly Back Booster. See HLCV Second 
Quarterly Review, Thursday 22 September 1988 for details. 


9.1.8 POWER SYSTEMS EXTENSION 

This GBT extension will be capable of testing new technologies in Power Systems 
components and architectures. This Phase 2 extension will support not only the normal 
evaluation of candidate power system sources and architectures, but will be focused on EMA 
power supply development and testing. 


9.1.9 FLUIDS & PNEUMATICS LAB 

This GBT extension facility contains the hardware and special test equipment needed to test 
the new Fluids and Pneumatic architectures and components. The Fluids & Pneumatics Lab 
contains flow and pressure sensing equipment, pressure regulation equipment, electronic 
valves, a facility processor, a VME bus input/output interface chassis, and bottled fluids and 
gases.The extension facility shall have thick safety walls and a pressure pit for this high 
pressure LN 2 . The facility shall also be capable of running remote when operating with the 
high pressure. 


9.1.10 ACTUATOR LAB 

This resource lab will provide a dynamic performance evaluation facility primarily aimed at 
larger, fast response actuators used in Trust Vector Control systems. With the emergence of 
large numbers of clustered engines as a solution to the heavy lift booster requirements, 

EMAs are gaining popularity. The advantages of being able to link the Power Systems and 
Actuator Labs together via the GBT is seen as an attractive Phase 2 capability. 

9.1.11 PROPULSION SYSTEMS LABS 

MSFC has long been the site of propulsion system development and test. The GBT would 
provide a way to combine the existing, high fidelity, .propulsion system hardware emulations 
and simulations with the avionics system simulations to provide integrated, end to end 
testing. Particularly useful will be the capability to evaluate control system performance using 
the clustered engine configurations of the future. 

9.2 GBT IMPLEMENTATION 

From the beginning, it was recognized that the Ground Based Test beds capabilities would 
be tied to meeting current program system testing requirements. The GBTs role was to 
encompass vehicle simulation and testing needs from inception to the Preliminary Design 
Review (PDR). Looking at the projected vehicle developmental schedules, it was all too clear 
that the first operational GBT capabilities would have to be focused on the critical 
developmental problems. If vehicles like the Shuttle C or STV were to be supported prior to 
their PDRs the GBT must be at least operational by August 1990. 
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Software model development is another key factor in the implementation plan. Fidelity of the 
vehicle dynamic and system models is critical to establishing the GBT as a valuable program 
development resource. This usually requires actual hardware being used to develop and 
verify the fidelity of the respective software models. Availability of similar hardware often 
proves to be another pacing element. The basic GBT hardware and software design is 
modular and thus can be changed easily to accommodate different requirements. The early 
phases of implementation require the building of a specific number of these basic modules to 
satisfy a limited number of needs. To satisfy a greater set of requirements relatively few new 
modules are required. 


LAB PRELIMINARY IMPLEMENTATION SCHEDULE 



Lab Program Drlvara 

• 4 Ytar Davalopmant Cycla 

• IOC First Launch. Da ii vary to pad 1 year prior to Launch. 

• Full Seals Engineering Development Systems Integration Laboratory with Pathfinder Activity 
• GBT Supports Early PDRs 


FIGURE 9.2-1 IMPLEMENTATION SCHEDULE 

Figure 9.2-1 shows an early implementation schedule and its assumptions. One of the most 
difficult problems of the implementation schedule, shown earlier in figure 1.2-2, is the amount 
of work to be done in the first phase. Between February 1989 and August 1 990, over 60% of 
the total task must be accomplished. This is not consist with the relatively low front end 
funding guidelines that were provided for this study. Figure 9.2-2 shows this problem 
graphically. 
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FIGURE 9.2-2 PROJECTED FUNDING LEVELS VS TASK 


9.3 GBT FUNDING 

The bottom line for GBT success is being able to supply the most cost effective and useful test 
facility at the time when new programs need it the most. This implies that the projects are 
willing to pay their way and plan for such usage initially. This idealistic form of funding must 
be recognized as supplemental to basic level of funding needed to initially implement and 
later maintain GBT operations. Internal Research & Development projects are also a source 
of funding. This type of function typically accelerates the application of useful, new 
technologies and test concepts upon which later major programs are built. 

Table 9.3-1 shows a summary of the element costs associated with the Phase 1 Ground 
Based Test Bed. Note that these are ROM costs with no wraps. More up to date, loaded 
costs are available in the Final Report Addendum. 


Page 41 


9/27/89, 8:43 AM 



